IBIS Macromodel Task Group

Meeting date: 08 February 2022

Members (asterisk for those attending):
Achronix Semiconductor:     * Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                            * Jared James
Google:                       Zhiping Yang
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                            * Majid Ahadi Dolatsara
                              Ming Yan
                            * Radek Biernacki
                            * Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                              Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Hansel said he had a new question about the IR for statistical flow that we
  could discuss.

-------------
Review of ARs:
  
- Fangyi to review Walter's draft of BIRD 211.4.
  - Done.  Fangyi had sent a new draft that included one correction.
  
- Walter to send out a new draft of BIRD213.1 addressing Randy's comments.
  - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the February 1st
meeting.  Randy moved to approve the minutes.  Ambrish seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD211.4 draft 2, IBIS AMI Reference Flow Improvements:
Arpad asked if we all agreed this was ready to send to the Open Forum, given
that Fangyi had completed his review and sent draft 2 to the ATM list.  Radek
moved that draft 2 be submitted to the Open Forum as BIRD211.4.  Walter seconded
the motion.  There were no objections.  Arpad took an AR submit BIRD211.4 to the
Open Forum.

BIRD213.1 draft 11, PAMn:
Walter shared draft 11.  He said one question that had arisen was, "If a model
supports PAM2, 3, and 4, then what should the model do with PAM_Thresholds and
PAM_Offsets if the user selects PAM2?"  These parameters would have to be
provided as Usage Out to support PAM3 and PAM4, but what should the model do
with them in PAM2?  Walter suggested that the model should be expected to return
a single-row table for each of the parameters, with the value of the row likely
to be zero.  He said this would be cleaner than adding language to the BIRD
stating that the parameters were optional in the case of PAM2.  Fangyi agreed
that for the sake of consistency the model should return PAM_Offsets and
PAM_Thresholds for any value of n.  Walter said we probably expect the values
to be zero in the case of PAM2, but allowing for non-zero values might turn out
out to be useful in the future.

Ambrish noted that he had always opposed requiring the model to return
PAM_Thresholds.  He said some models may return bad thresholds, and the tools
will have to handle that scenario anyway.  Walter said that in discussing this
BIRD with model makers there had been universal agreement that if the model
doesn't know its own thresholds its results are likely to be nonsense.

Fangyi said that Type Integer should not be allowed for PAM_Thresholds.  He said
only Float should be allowed.  Walter agreed and removed Integer.

Fangyi and Arpad commented on the definition of "reference row" in the Usage
Rules for PAM_Offsets.  Fangyi said that for time-domain simulation we don't
need any concept of a reference row at all.  PAM_Offsets simply provides n-1
independent offsets to be applied to the single set of clock times returned in
clock_times.  Walter agreed that the reference row discussion could be removed
for time-domain.

Walter said that for statistical simulation you need to define the reference
row since you don't have clock_times.  If Rx_Decision_Time is provided, then
that can be the starting point for the offsets.  Fangyi agreed, and asked that
we define the behavior with an equation.  For example:
  If t0 is the Rx_Decision_Time, or the center of the nominal eye as computed
  by the EDA tool if Rx_Decision_Time is not provided, then the sampling time
  of the kth eye is t0 + kth row of PAM_Offsets.
  Note: this assumes PAM_Offsets already includes Rx_Recovery_Mean.
  
Walter said he would add similar language to the BIRD.

The group reviewed comments Arpad had submitted via email.  In the text to be
modified on page 228, Arpad questioned what was meant by "the electrical
interface to either the driver or receiver is differential".  The group agreed
that this was not meant to imply that single-ended and differential could be
mixed, and it should have said "both the driver and receiver".  Fangyi and
Walter said we aren't really talking about the physical/electrical interface.
We are talking about the model interface.  Walter said when AMI was originally
introduced it only considered differential devices, and Fangyi said now with the
DC_Offset parameter the input waveform to GetWave is differential even when
modeling single-ended devices.  Arpad said this sentence would need additional
work.  Fangyi suggested the entire sentence should simply be removed.  It was
not helpful, and everything it mentioned was already defined elsewhere.  Walter
agreed and removed the sentence entirely.

Arpad said the first sentence of Usage Rules for Modulation_Levels:
  "It is declared as Type Integer."
should be removed.  He said this was redundant because it was specified in the
Type information.  Walter agreed and removed the sentence.

Arpad asked Michael Mirmak to comment on "must" and "must not" vs "shall" and
"shall not".  Michael said that we use "shall" for rules we are defining.  For
things we don't directly control, for example, EDA tool behavior, we can say
they "must".  Based on this input, Walter changed one instance of "cannot" to
"shall not" in the Usage Rules for Modulation_Levels.

In the Usage Rules for PAM_Thresholds, Arpad said the following language was
confusing:
  "The eye with the lowest voltage ..."
  
Walter said it should say, "lowest threshold voltage".  Radek, Arpad and others
said the language describing the sequence of eyes with progressively higher
threshold voltages should be improved.

Ambrish asked why we needed the complication of using use Tables for these
PAM parameters.  Why couldn't they be defined as a simple String parameters
whose values would contain a space delimited sequence of thresholds or
offsets?

Walter said he would send out a draft 12.

- Michael: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

AR: Arpad to submit BIRD211.4 to the Open Forum.
AR: Walter to send out BIRD213.1 draft 12 incorporating today's changes.
-------------
Next meeting: 15 February 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
